پرش به محتوا

جداسازی جدول صفحه هسته

از ویکی‌پدیا، دانشنامهٔ آزاد
دسته اول از جداول صفحه، شامل آدرس‌های فضای حافظهٔ کاربران و هسته مانند قبل وجود دارد که تنها در حالت هسته قابل دسترسی هستند. دسته دوم از جداول صفحه که برای استفاده کاربران می‌باشد، شامل یک نسخه از فضای آدرس‌دهی حافظهٔ کاربر و یک مجموعهٔ حداقلی از فضای آدرس‌دهی حافظهٔ هسته که اطلاعات مورده نیاز برای ارسال و دریافت فراخوان‌های سیستمی، وقفه‌ها و استثناءها را فراهم می‌آورد، می‌باشد.

جداسازی جدول صفحهٔ هسته (Kernel page-table isolation یا KPTI)[۱][۲] یکی از ویژگی‌های هسته لینوکس است که سبب کاهش اثر آسیب‌پذیری امیتی Meltdown (که بیشتر بر روی پردازنده‌های مدل x86 شرکت اینتل رخ می‌دهد)[۳] و افزایش مقاومت هستهٔ لینوکس در برابر تلاش‌هایی به منطور دور زدن سازوکار KASLR می‌شود. این ویژگی با جداسازی بهتر فضای آدرس کاربر و فضای آدرس هسته لینوکس در حافظهٔ کار می‌کند.[۴][۵] KPTI ابتدا در نسخه لینوکس ۴٫۱۵ ارائه شد سپس به نسخه‌های قبلی ۴٫۱۴٫۱۱، ۴٫۹٫۷۵، و ۴٫۴٫۱۱۰ نیز افزوده شد. سیستم‌های عامل Windows و macOS نیز این ویژگی را به خودشان اضافه کردند. KPTI آسیب‌پذیری Spectre را پوشش نمی‌دهد.

پیش‌زمینه دربارهٔ KAISER

[ویرایش]

KPTI در واقع مبتنی بر KAISER (یک تکنیک به نام جداسازی فضای آدرس هسته به منظور حذف مؤثر کانال‌های جانبی) طراحی شده‌است. روش KAISER در سال ۲۰۱۶ طراحی شد[۶] و در سال ۲۰۱۷ منتشر شد هنگامی که هنوز آسیب‌پذیری Meltdown شناخنه نشده بود. KAISER باعث افزایش مقاومت KASLR، که روشی ارائه شده برای یک موضوع کم‌اهمیت‌تر در سال ۲۰۱۴ بود، می‌شود.

در سال ۲۰۱۴ قابلیت تصادفی‌سازی چیدمان فضای آدرس هسته(KASLR)[۷] به هستهٔ لینوکس اضافه شد. این قابلیت سبب سخت‌تر شدن بهره‌برداری از دیگر آسیب‌پذری‌های هسته لینوکس که به دلیل آدرس‌دهی فضای حافظهٔ هسته که از دید کاربران مخفی می‌ماند، به وجود می‌آمدند، می‌شد. با وجود جلوگیری از دسترسی به فضای آدرس‌دهی حافظه هسته، مشخص شد چندین کانال جانبی در پردازنده‌های امروزی وجود دارند که سبب مشخص شدن فضای آدرس هسته در حافظه حتی در حضور KASLR می‌شوند.

KAISER این مشکلات موجود در KASLR را با حذف تعدادی از منابع که باعث نشت آدرس می‌شدند حل می‌کند. در حالیکه KASLR تنها از نشت اطلاعات آدرس‌دهی جلوگیری می‌کند، KAISER علاوه بر آن از نشت خود داده‌ها هم جلوگیری می‌کند که سبب پوشش آسیب‌پذیری Meltdown می‌شود.

KPTI بر اساس KAISER طراحی شده‌است. هنگامی که KPTI غیرفعال است، هرگاه که کدی در فضای آدرس کاربران (به‌طور کلی برنامه‌های کاربردی) اجرا شود، لینوکس تمامی حافظهٔ هسته خود را که در جداول صفحه (Page Tables) آدرس‌دهی شده‌اند را حفظ می‌کند و از آن‌ها در مقابل دسترسی محافظت می‌کند. مزیت این روش این است که وقتی یک برنامه یک فراخوان سیستمی (System call) تولید می‌کند یا یک سیگنال وقفه دریافت می‌شود، جداول صفحهٔ هسته همواره حاضر هستند که سبب می‌شود بتوان از بیشتر سربارهای مربوط به عملیات context switch (مانند TLB Flush و page-table swapping و ..) جلوگیری کرد.

آسیب‌پذیری Meltdown و KPTI

[ویرایش]

در ژانویه سال ۲۰۱۸، آسیب‌پذیری Meltdown معرفی شد که بر روی پردازنده‌های مدل x86 شرکت اینتل و ARM Cortex-A75 تأثیر می‌گذاشت. این آسیب‌پذیری بسیار بدتر از نشت آدرس‌های فضای حافظه هسته در KASLR بود که KAISER قصد جلوگیری از آن را داشت. این موضوع آشکار شد که بر خلاف آنچه تاکنون پنداشته می‌شد، نه تنها مکان‌های نگاشت حافظه بلکه خود اطلاعات هسته لینوکس می‌توانند نشت پیدا کنند.

KPTI با جلوگیری از نگاشت فضاهای حفاظت شده به فضای آدرس‌دهی کاربران از آسیب‌پذیری Meltdown جلوگیری می‌کند.

در پردازنده‌های مدل x86 شرکت amd تا به حال رخداد آسیب‌پذری Meltdown مشاهده نشده‌است و این پردازنده‌ها نیازی به KPTI ندارند.[۳][۸] با این وجود این پردازنده‌ها مستعد دور زده شدن KASLR هنگامی که KPTI غیرفعال است، هستند.

پیاده‌سازی

[ویرایش]

KPTI از این نشت‌ها با جداسازی کامل جداول صفحهٔ فضای حافظهٔ کاربران و هسته، جلوگیری می‌کند. دسته اول از جداول صفحه شامل آدرس‌های فضای حافظهٔ کاربران و هسته مانند قبل وجود دارد که تنها در هنگامی که سیستم در حالت هسته کار می‌کند قابل دسترسی هستند. دسته دوم از جداول صفحه که برای استفاده کاربران می‌باشد، شامل یک نسخه از فضای آدرس‌دهی حافظهٔ کاربر و یک مجموعهٔ حداقلی از فضای آدرس‌دهی حافظهٔ هسته که اطلاعات مورده نیاز برای ارسال و دریافت فراخوان‌های سیستمی، وقفه‌ها و استثناءها را فراهم می‌آورد، می‌باشد.

در پردازنده‌هایی که از ویژگی process-context identifiers (PCID) پشتیبانی می‌کنند، می‌توان از یک مرتبه خالی کردن بافر TLB پرهیز کرد، اما با وجود نیز هزینه محاسباتی بسیار زیادی خصوصاً در هنگام فرخوان‌های سیستمی و وقفه‌های سنگین به سیستم تحمیل می‌شود.

سربار محاسباتی محاسبه شده توسط خود طراحان اصلی KAISER برابر %۰٫۲۸ بود. با وجود این یک توسعه‌دهندهٔ لینوکس این مقدار را برای بیشتر بازهٔ کاری تقریباً ۵٪ و در بعضی شرایط خاص حتی با وجود بهینه‌سازی PCID سربار محاسباتی تا %۳۰ بالا می‌رود. مقدار سربار محاسباتی در آزمایش بر روی پایگاه‌داده PostgreSQL هنگام عملیات‌های تنها خواندن با یک پردازندهٔ مدل Skylake شرکت اینتل برابر %۱۷–۷ (یا %۲۳–۱۶ بدون PCID)[۹] بود، در حالی که هنگام آزمایش کامل این میزان در بازهٔ %۱۹–۱۳ قرار داشت.[۱۰] در بسیاری از سنجش‌های انجام شده که بر روی پایگاه‌داده‌های Phoronix و Redis انجام شده‌اند کاهش سرعت در بازهٔ %۷–۶ می‌باشد. کامپایل هسته لینوکس نیز حدود %۵ بر روی پردازنده‌های مدل Haswell کندتر شد.[۱۱]

KPTI را می‌توان با گزینه ”nopti“ در boot هسته غیرفعال کرد. همچنین تمهیداتی در نظر گرفته شده‌است تا اگر در پردازنده‌های جدید جلوی نشت اطلاعات گرفته شد بتوان KPTI را غیرفعال کرد.

منابع

[ویرایش]
  1. Corbet, Jonathan (2017-12-20). "The current state of kernel page-table isolation". LWN.net.
  2. Cimpanu, Catalin (2018-01-03). "OS Makers Preparing Patches for Secret Intel CPU Security Bug". Bleeping Computer (به انگلیسی).
  3. ۳٫۰ ۳٫۱ "Spectre, Meltdown: Critical CPU Security Flaws Explained – ExtremeTech". ExtremeTech (به انگلیسی). 2018-01-04. Retrieved 2018-01-05.
  4. Corbet, Jonathan (2017-11-15). "KAISER: hiding the kernel from user space". LWN.net.
  5. Gruss, Daniel; Lipp, Moritz; Schwarz, Michael; Fellner, Richard; Maurice, Clémentine; Mangard, Stefan (2017-06-24). KASLR is Dead: Long Live KASLR (PDF). Engineering Secure Software and Systems 2017.
  6. Gruss, Daniel (2018-01-03). "#FunFact: We submitted #KAISER to #bhusa17 and got it rejected". Archived from the original on 2018-01-08. Retrieved 2018-01-08 – via Twitter.
  7. "Linux kernel 3.14, Section 1.7. Kernel address space randomization". kernelnewbies.org. 2014-03-30. Retrieved 2014-04-02.
  8. "An Update on AMD Processor Security". AMD. 2018-01-04.
  9. Freund, Andres (2018-01-02). "heads up: Fix for intel hardware bug will lead to performance regressions". PostgreSQL development mailing list (pgsql-hackers).
  10. Larabel, Michael (2018-01-02). "Initial Benchmarks Of The Performance Impact Resulting From Linux's x86 Security Changes". Phoronix.
  11. Velvindron, Loganaden (2018-01-04). "Linux KPTI performance hit on real workloads". Loganaden Velvindron. Retrieved 2018-01-05.